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(54) Packet multicasting in network for providing various QOS 



(57) A mechanism for performing multicast packet 
transfer when a certain one of the destination nodes par- 
ticipating In the mutticast communication requires re- 
source reservation for a certain packet flow specified 
among the packet flows to that destination node. A sys- 
tem may transfer multicast packets using a plurality of 
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virtual connections based on which flow the packets to 
be transferred belong to, so that each node receives the 
packets without duplication. Alternatively, a system may 
selectively discard received packets to avoid processing 
duplicated packets, although duplicated packets are re- 
ceived at each node. 
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Description 

BACKGROUND OF THE INVENTION 

A. Field of the Invention 

The present invention relates to a router that con- 
nects virtual-connection-oriented networks and a meth- 
od NArfiereby multicast packets are transferred to a dif- 
ferent logical network through a router. 

B. Description of the Background Art 

A router is employed in connecting logical networks; 
it performs the function of transferring packets from one 
logical network to another logical network. A packet, in 
addition to containing communication information data 
that Is to be transferred, contains network layer address- 
es of its source and final destination. Using the destina- 
tion address, the router determines the output interface 
of the packet and the next-hop node to which the packet 
is to be transferred. 

Such a router device, in addition to providing uni- 
cast communication in which packets are transferred 
from one source node to one final destination node, is 
also capable of multicast communication, in which pack- 
ets are sent from a single source to a plurality of desti- 
nation nodes. 

In recent years, resource reservation at the router 
has been used when audio and/or pictures are trans- 
ferred using packets. Transferring audio/pictures and 
other data without resource reservation results in bro- 
ken audio and corrupt video. The resource reservation 
technique is useful not only in transferring information 
which requires a certain desired transfer rate, such as 
audio and pictures, but also in transferring high priority 
data. 

In order to perfonn resource reservation at the rout- 
er, resource reservation infonmation is exchanged be- 
tween nodes, including routers. One protocol currently 
being developed for resource reservation, RSVP (Re- 
source reservation Protocol), applies to both unicast 
and multicast. 

In RSVP, resource reservation is performed from a 
destination node to a source node. Specifically, a PATH 
message is sent from node to node along a path in a 
direction flowing from the source node to the destination 
node. Routers along this path store information regard- 
ing the path on which the data is to be transferred based 
on the PATH message. This PATH message contains 
an identifier specifying the packet flow for which the re- 
source reservation is to be performed and an IP address 
of the node that sent the PATH message. 

When the destination node receives the PATH mes- 
sage, it makes its request for resource reservation by 
sending an RESV message upstream, back to the 
source node in response to the PATH message. This 
RESV message contains an identifier specifying the 



packet flow for which resources are to be reserved. In 
RSVP, for example, this identifier is called Flow ID The 
RESV message also contains a quality of service (QOS) 
requested by the destination node. 

s When a router receives the RESV message, It de- 
termines whether its network-layer (e.g., Intemet Proto- 
col (IP)) processing section has sufficient capacity for 
this resource reservation. If so, the router performs net- 
work-layer scheduling to reserve the resources and 

10 transfers the RESV message upstream. If not, the router 
sends an RESV_ERROR message downstream. This 
procedure is repeated until the RESV message reaches 
the source node, thereby completing the resource res- 
ervation. 

IS If a Local Area Network (LAN) constituting a logical 
network Is implemented by a virtual-connection-orient- 
ed network, and resource reservation is effected in mul- 
ticast communication in response to a request from a 
certain receiving (destination) node, resource reserva- 

20 tion within the LAN can be implemented by creating one 
point-multipoint virtual connection (VC) with resource 
reservation for one multicast address and also creating 
another "best effort" point-multipoint VC (i.e., with no re- 
source reservation) for the same multicast address. 

2S For example, when sending a multicast packet of 
destination address G to receiving (destination) nodes 
H1 , H2, H3 and H4 from sending (source) node S, if HI 
and H2 have requested QOS but H3 and H4 have not 
requested QOS, there are set up a point-multipoint VC 

30 with the requested QOS for destination address G to HI , 
H2 from S and another "best effort* point-multipoint VC 
for destination address G to H3, H4 from S. 

However, the conventional technology has not con- 
skJered a situation where a receiving node requests 

55 QOS for a specified applicatk>n, like video conference, 
but does not request QOS for the other applications 
working on the identical receiving node. 

For example, if two VCs, one of which is with QOS 
and the other of which is "best effort", are set up to reach 

^ one downstream node and an upstream node dupli- 
cates a packet to transmit each packet through each VC 
because both VCs are related to the same destination 
address, the downstream node will receive two packets 
kjentical to each other. If the downstream node operates 

45 liKe above to transfer the received packets to a further 
ctownstream node, the further downstream node will re- 
ceive four packets identical to one another The number 
of identical packets is doubled every time the multicast 
tree is traced. 

50 Another recently developed technique for transfer- 
ring packets at a higher rate is a Cell Switched Router 
(CSR). This is a particular type of router that has a da- 
tali nk-layer switch to transfer packets in addition to a 
network-layer processing section (an ordinary router 

55 software for packet forwarding). This technotogy makes . 
it possible for a router to transfer packets at a layer lower 
than the network layer by directly linking an input virtual 
connection (VC) and an output VC through the switch. 
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However, when this technology is applied to multi- 
cast packet transfer, packets may not be delivered to 
some of the receiving parties that participate in the mul- 
ticast group, if the direct linking is not performed for all 
the receiving parties and multicast packets only flow on- 
to the VC that is directly linked. 

On the other hand, if- packets flow onto two VCs, 
one of which is directly linked and the other of which is 
not directly linked (supposed to be used for hop-by-hop^ 
transfer), the above-mentioned packet duplication may 
occur. 

SUMMARY OF THE INVENTION 

It is therefore an object of the present invention to 
provide a mechanism for performing an efficient and ad- 
equate multicast packet transfer when a certain one of 
the destination nodes participating in the multicast com- 
munication requires resource reservation for a certain 
packet flow specified among the packet flows to that 
destination node. 

Another object of the present Invention is to provide 
a mechanism for performing an efficient and adequate 
multicast packet transfer when a router has a function 
for directly linking virtual connections belonging to dif- 
ferent logical networks. 

Yet another object of the present invention is to 
achieve high-speed packet transfer by lightening the 
load on the network-layer processing section when one 
packet is output by a router to a plurality of virtual con- 
nections. 

According to one aspect of the present invention, 
there is provided a mechanism for transferring a packet 
destined for a plurality of destination nodes in multicast 
communication, in a network having a first node and a 
plurality of second nodes. The mechanism sets up a plu- 
rality of virtual connectbns in the network, each of the 
plurality of virtual connections being set up from the first 
node to one or more of the plurality of second nodes; 
and transmits a plurality of packets destined for the des- 
tination nodes from the first node using the plurality of 
virtual connections, so that each of the plurality of sec- 
ond nodes receives the plurality of packets destined for 
the destination nodes without duplication through one 
or more of the plurality of virtual connections and at least 
one of the plurality of second nodes receives the plural- 
ity of packets through at least two of the plurality of vir- 
tual connections. 

According to another aspect of the present inven- 
tion, a mechanism sets up a first virtual connection from 
the first node to the plurality of second nodes; sets up a 
second virtual connection from the first node to at least 
a specified one of the plurality of second nodes: trans- 
mits a plurality of packets from the first node, so that 
each of the plurality of second nodes receives the pack- 
ets destined for the destination nodes through the first 
virtual connection and at least the specified one of the 
plurality of second nodes receives the packets destined 



for the destination nodes and belonging to a specified 
flow also through the second virtual connection: and dis- 
cards the packets destined for the destination nodes 
and belonging to the specified flow received through the 

5 first virtual connection at the specified node. 

According to yet another aspect of the present in- 
vention, there is provided a mechanism for transferring 
a packet from a first node belonging to one logical net- 
work to a second node belonging to another logical net- 

10 work, comprising: a memory for storing a correspond- 
ence relationship between a first virtual connection for 
receiving a packet from the first node and a second vir- 
tual connection for transmitting the packet to the second 
node; first means for transferring a packet received from 

15 the first node to a next-hop node detenmined by analyz- 
ing a destination address contained in the packet; sec- 
ond means for transferring a packet destined tor a plu- 
rality of destination nodes in multicast communication 
received through the first virtual connection onto the 

20 second virtual connection in accordance with the corre- 
spondence relationship, when the correspondence re- 
lationship is stored in the memory; and means for cop- 
ying the packet received through the first virtual connec- 
tion to hand over the packet to the first means, when it 

25 IS detenmined that the next-hop node will not receive the. 
packet destined for the destination nodes if the packet, 
is transferred only by the second means. 

According to yet another aspect of the present ior:. 
vention, there is provided a mechanism comprising: a 

30 memory for storing a correspondence relationship be- 
tween a first virtual connection for receiving a packet 
from the first node and a second virtual connection for 
transmitting the packet to the second node; first means 
for transferring a packet received from the first node to 

35 a next-hop node determined by analyzing a destination . 
address contained in the packet; second means for 
transferring a packet received through the first virtual 
connection onto the second virtual connection in ac- 
cordance with the stored correspondence relationship, 

40 when the correspondence relationship is stored in the 
memory; and means for discarding a packet received 
through another virtual connection different from the first 
virtual connection before the packet is handed over to 
the first means, when the packet received through said 

45 another virtual connection is identical to the packet re- 
ceived through the first virtual connection. 

According to yet another aspect of the present in- 
vention, there is provided a mechanism for transferring 
a packet destined for a plurality of destination nodes in 

so multicast communication from a first node belonging to 
one logical network through a switch for exchanging the 
packet to a second node and a third node belonging to 
another logical network different from said one logical 
network. The mechanism stores a correspondence re- 

55 lationship between a first virtual connection for transfer- 
ring a packet and a secorKl virtual connection for trans- 
mitting the packet to the second node and a third virtual 
connection for transmitting the packet to the third node; 
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transfers a packet received from the first node through 
the first virtual connection to the switch by analyzing a 
destination address contained in the packet; and trans- 
fers, by the switch, the packet received through the first 
virtual connection onto the second and third virtual con- 
nections in accordance with the stored correspondence 
relationship. 

Other features and advantage of the present inven- 
tion will be become apparent from the following descrip- 
tion taken in conjunction with the accompanying draw- 
ings. 

Both the foregoing general description and the fol- 
lowing detailed description provide examples consistent 
with this invention and explain how to make and use sys- 
tems and methods consistent with the invention. These 
description do not restrict the claimed invention. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 is an exemplary network topology and ordi- 
nary virtual connections. 

Fig. 2 is an exemplary network topology and virtual 
connections according to specific example I of embod- 
iment 1 . 

Fig. 3 is a functional block diagram showing an ex- 
emplary configuration of sending node. 

Fig. 4 is a functional block diagram showing an ex- 
emplary configuration of router according to embodi- 
ment 1 . 

Fig. 5 is a flow chart showing an exemplary output 
processing procedure of packets in the network-layer 
processing section. 

Fig. 6(a) and Fig. 6(b) show exemplary contents of 
the routing table in the sending node according to spe- 
cific example I of embodiment 1 . 

Fig. 7(a) and Fig. 7(b) show exemplary contents of 
the routing table in the router according to specific ex- 
ample 1 of embodiment 1 , 

Fig. 8 is an exemplary network topology and virtual 
connections according to specific example 2 of embod- 
iment 1 . 

Fig. 9(a) and Fig. 9(b) illustrate exemplary contents 
of the routing table in the sending node according to spe- 
cific example 2 of embodiment 1 . 

Fig. 10(a) and Fig. 10(b) Illustrate exemplary con- 
tents ofthe routing table in the router according to spe- 
cific example 2 of embodiment 1 . 

Fig. 1 1 is an exemplary network topology and virtual 
connections according to specific example 3 of embod- 
iment 1 . 

Fig. 12(a) and Fig. 12(b) illustrate exemplary con- 
tents of the routing table in the sending node according 
to specific example 3 of embodiment 1. 

Fig. 13(a) and Fig. 13(b) illustrate exemplary con- 
tents of the routing table in the router according to spe- 
cific example 3 of embodiment 1 . 

Fig. 14 is an exemplary network topology and virtual 
connections according to embodiment 2. 



Fig. 15 is a flow chart showing another exemplary 
output processing procedure of packets in the network- 
layer processing section. 

Fig. 16(a) and Fig. 16(b) illustrate exemplary con- 
s tents of the routing table in the sending node according 
to embodiment 2. 

Fig. 1 7 is a functional block diagram showing an ex- 
emplary configuration of a router according to embodi- 
ment 2. 

10 Fig. 18(a) and Fig. 18(b) each illustrate exemplary 
contents of the routing table in the router according to 
embodiment 2. 

Fig. 1 9 is exemplary contents of the packet discard- 
ing table according to embodiment 2. 

IS Fig. 20 is a functional block diagram showing an ex- 
emplary configuration of a receiving node according to 
embodiment 2. 

Fig. 21 is a diagram given in explanation of the op- 
eration of CSR. 

20 Fig. 22 is a functional block diagram showing an ex- 
emplary configuration of the CSR according to specific 
example 1 of embodiment 3. 

Fig. 23 is an exemplary VC set-up diagram in the 
CSR according to specific example 1 of embodiment 3. 

2S Fig. 24 is a flow chart showing an exemplary oper- 
ation of the ATM switch according to embodiments 3 to 
5. 

Fig. 25 is a flow chart showing an exemplary oper- 
ation of the IP processing section according to specific 
30 examples 1 and 3 of embodiment 3. 

j Fig. 26(a) and Fig. 26(b) each illustrate exemplary 
contents of the ATM routing table according to specific 
example 1 of embodiment 3. 

Fig. 27(a) and Fig. 27(b) each illustrate exemplary 
35 contents of the IP routing table according to specific ex- 
ample 1 of embodiment 3. 

Fig. 28 is exemplary contents of the input VC v. flow 
table according to specific example 1 of embodiment 3. 

Fig. 29 is a functional block diagram showing an ex- 
40 emplary configuration of the CSR according to specific 
examples 2 and 3 of embodiment 3. 

Fig. 30 is an exemplary VC set-up diagram in the 
CSR according to specific example 2 of embodiment 3. 

Fig. 31(a) and Fig. 31(b) each illustrate exemplary 
46 contents of the ATM routing table according to specific 
example 2 of embodiment 3. 

Fig. 32(a) and Fig. 32(b) each illustrate exemplary 
contents of the IP routing table according to specific ex- 
ample 2 of embodiment 3. 
so Fig. 33(a) illustrates exemplary contents of the 
packet discarding table and Fig. 33(b) illustrates con- 
tents of the input VC v, flow table, according to specific 
example 2 of embodiment 3. 

Fig. 34 is an exemplary VC set-up diagram in the 
55 CSR in a given condition according to specific example 
3 of embodiment 3. 

Fig. 35(a) and Fig. 35(b) illustrate exemplary con- 
tents of the IP routing table. Fig. 35(c) illustrates exem- 
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plary contents of the packet discarding table, and Fig. 
35(d) illustrates exemplary contents of the input VC v. 
flow table, in said given condition according to specific 
example 3 of embodiment 3. 

Fig. 36 is an exemplary VC set-up diagram In the 
CSR in another condition according to specific example 
3 of embodiment 3. 

Fig. 37(a) and Fig. 37(b) illustrate exemplary con- 
tents of the IP routing table. Fig. 37(c) illustrates exem- 
plary contents of the packet discarding table, and Fig. 
37(d) illustrates exemplary contents of the input VC v. 
f low table, in said another condition according to specific 
example 3 of embodiment 3. 

Fig. 38 is an exemplary VC set-up diagram in the 
CSR according to embodiment 4. 

Fig. 39(a) and Fig. 39(b) illustrate exemplary con- 
tents of a direct-link management table according to em- 
bodiment 4. 

Fig. 40(a) and Fig. 40(b) illustrate exemplary con- 
tents of the ATM routing table according to embodiment 
4. 

Fig. 4 is an exemplary VC set-up diagram in a router 
according to embodiment 5. 

Fig. 42(a) and Fig. 42(b) illustrate exemplary con- 
tents of an IP routing table according to embodiment 5. 

Fig. 43(a) and Fig. 43(b) illustrate exemplary con- 
tents of the ATM routing table of embodiment 5. 

DETAILED DESCRIPTION OF THE PREFERRED 
EMBODIMENTS 

The following are terms and explanations relating 
to the present invention. 

A 'host' means an apparatus that sends and re- 
ceives packets. A "router" means an apparatus that not 
only sends and receives packets but also transfers 
packets from one logical network to another logical net- 
work. A "node" indicates either a host or a router, which 
can process packets at the network layer. 

A "node connected to a virtual-connection-oriented 
network" means a node having an interlace that can 
transmit or receive packets having virtual connection 
identifiers attached. For example, a virtual connection 
can be set up, such as Asynchronous Transfer Mode 
(ATM) not only in a case where there is one or more 
switch within the logical network, but also a case of a 
point-point physical link in which the logical network 
does not include a switch. 

A ■point-multipoint VC" indicates a virtual connec- 
tion wherein, when one packet is sent from a source 
node, a plurality of packets arrive at a plurality of receiv- 
ing parties. If the receiving parties comprise only a single 
node, the VC is similar to a point-point VC, but the VC 
is stilt called a point-multipoint VC. 

A "destination address" indicates a destination net- 
work-layer address and includes not only a unicast ad- 
dress but also a group address of mutticast. 

A "flow" indicates a group of packets specified by 



some information. For example, a flow may be a group 
of packets having at least a specified destination ad- 
dress. The destination address may be a destination ad- 
dress prefix that can signify a destination network. As 

s the information for specifying the flow, a destination port 
number of the transport layer can be used in addition to 
the destination address. Also, a source address can be 
used The "transport layer destination port number" sig- 
nifies a certain specific application at the destination 

10 node, so the flow may be specified alternatively by an 
identifier having the same nneaning as this. In Intemet 
Protocol Version 6 (IPv6), a packet group containing a 
specific Flow ID, instead of specific destination address, 
can also be the specified flow. 

IS A "virtual connection to be used to transmit packets 
for which different QOS is requested" can be a VC with 
a different bandwidth, or a VC for which different re- 
source reservation Is effected by either node of the ends 
of the VC. Also, a VC directly linked through a switching 

20 function at a layer lower than the network layer at either 
router of the ends of the VC can be a VC for which dif- 
ferent QOS than a VC for ordinary hop-by-hop transfer 
is requested. The case where "different QOS is request- 
ed" includes a case where some QOS is requested for 

2S one flow and no QOS is requested for another flow. VCs 
with different resources maybe a VC with some resourc- 
es and a VC with no resource. 

A "virtual connection from a given node to a plurality 
of other nodes" can be a point-multipoint VC from a giv- 

30 en node to a plurality of other nodes, or a group of point- 
point VCs from a given node to a plurality of other re- 
spective nodes. Alternatively it may be a combination 
of point-multipoint VC to some nodes and point-point 
VCs to other nodes. Or it may be a point-point VC from 

35 a given node to a multicast server and the aforesaid VC 
<s) from the multicast server to a plurality of nodes. 

(Embodiment 1 ) 

40 This embodiment provides a scheme (specific ex- 
amples 1 through 3) of implementing multicast packet 
transfer with different QOS requests, in which reception 
of multicast packets by each node can be achieved with- 
out duplrcation. An advantage of this embodiment is that 

45 network resources can be efficiently utilized, since no 
duplicated packets flow Into the network. 

(Embodiment 1 , Specific example 1 ) 

so Fig. 1 shows a network topology described in this 
embodiment. The nodes constituting the networks com- 
prise a host (S) sending multicast packets, routers (R1 , 
R2, R3) that transfer the packets, and receiving hosts 
(H1 , H2 ... H7). Sending host S has a single interface (1/ 

ss F), called "a" R3 has three l/Fs, naimely, "a." "b," and "c." 
In this layout, hosts are connected upstream and 
downstream of a router For example, sending host (S) 
communicates through router (R1) with receiving host 
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(HI). Similar operation is performed when routers are 
connected upstream and do\Affistream of router (R1 ). 
For example, sending host (S) can communicate 
through a router, router (R1), and another router with 
receiving host (HI). 

Each of the nodes belongs to one or more subnet 
(logical network). A "subnet" is an area In which com- 
munication can be effected directly without going 
through a router For communication from to outside of 
the subnet, packet transfer using a router is required. 

The nodes that belong to the same subnet in the 
layout of Fig. 1 are as follows: (S, R1 , R2, R3) belongs 
to subnet A; (R1 , HI , H2) belongs to subnet B; (R2, H3) 
belongs to subnet C; (R3, H4, H5 belongs to subnet D; 
and (R3, H6. H7) belongs to subnet E. The nodes are 
mutually connected through a virtual-connection-orient- 
ed network within the subnet. 

A method of transfer of multicast packets of desti- 
nation address G and source address S for the case of 
the above layout will now be described. The nodes be- 
longing to the group of destination address G are taken 
to be H1, H3, H4, H5 and H7. 

Virtual connections as shown in Fig. 1 are set up in 
a case where the QOS is just "best effort" (no QOS). 
When sending multicast packets of destination address 
G from sending host S. distribution is effected through 
VCO to R1, R2 and R3. \Nhen R1 receives these pack- 
ets, it distributes the packets to HI ; R2 distributes the 
packets to H3; R3 distributes the packets to H4 and H5 
by VC2 and distributes the packets to H7 by VC4- 

In Fig. 1 , the multicast packets are transferred using 
point-multipoint VCs; however, a multicast server can 
be empk>yed alternatively. In the following examples, 
where a multipoint-point VC is employed, it is also pos- 
sible to employ a multicast server A multicast server 
transfers packets received from a point-point VC onto a 
point-multipoint VC. 

An example where, from a condition as shown in 
Fig. 1 , H5 has requested QOS for packets of destination 
address G and destination port number 1 is now de- 
scribed. The QOS request can be transmitted using a 
resource reservation protocol, such as RSVP. Another 
QOS request protocol capable of notifying a neighboring 
node of the requested QOS may be used. 

As shown in Fig. 2, when QOS has been requested 
from H5 under RSVP, R3 sets up a point-mutti point VC 
(VCS) from output l/F (b), in order to transfer packets of 
destination address G and destination port number 1 to 
nodes (H4, H5) participating in group G in the same sub- 
net (subnet D). In the drawings the VC indicated by the 
dotted line and the VC indicated by the continuous line 
are respectively associated with different QOS requests 
in regard to the packets to be transferred thereby. VC3 
is employed to transfer packets of destination address 
G and destination port number 1. VC2, which had hith- 
erto transferred all packets of destination address G. 
starts to transfer packets of destination address G ex- 
cluding the packets of destination address G and desti- 



nation port number 1 which are flowing onto VC3. 

R3 transfers the QOS request to S, and S sets up 
VC1, in a similar way as VC3. S transmits the packets 
that are to be transferred by VC3 onto VC 1 , while trans- 
5 mitting the packets that are to be transferred by VC2 
onto VCO. If the QOS request is transferred by using 
RSVP, the request is transferred in this way from a 
downstream node to an upstream node. If another 
scheme is employed as the QOS request protocol, it 
10 rnay be transferred in a different manner However, 
whichever method of QOS request transfer is adopted, 
VC set-up is finally performed as shown in Fig. 2. 

Essentially, a new point-multipoint VC, each leaf of 
which heads for each one of all the receiving parties be- 
15 longing to the multicast group in the same subnet, is set 
up for the flow for which the QOS was requested. Set- 
up is effected such that packets of the flow for which 
QOS was requested are transferred through the newly 
established VC while the Identical packets are not trans- 
ferred through the old existing best-effort VC. 

Since no QOS was requested regarding output \/T 
(c) of R3, all the packets of destination address G are 
transferred by the best-effort VC (VC4). 

Next, a method of transfer of multicast packets onto 
VCO and VC1 at sending node (S ). and onto VC2, VC3 
and VC4 at router (R3) will be described in detail. 

Sending node S has a configuration as shown in 
Fig. 3, Packets are sent through network IF (13) in ac- 
cordance with the flowchart shown in Fig. 5 by output 
processing section (11). Network-layer processing sec- 
tion (10) includes output processing section (11) and 
routing table (1 2 ) Output processing section (11 ) refers 
to routing table (12). (n the following description. Fig. 6 
is used as an example of routing table (12). This routing 
table is set up when multicast routing protocol is ex- 
changed or QOS is requested. 

The procedure whereby multicast packets of source 
S, destinatbn G, destination port 1 (hereinafter ex- 
pressed as (S, G, 1)) are transferred wilt be described. 
An output VC pointer is obtained (SI ) by searching rout- 
ing table (a) (Fig. 6(a)), using the set: (source, destina- 
tion, destination port) of. the packet as a key. 

In this search process, the source and destination 
addresses of the selected entry in the routing table (a) 
are required to coincide with the source and destination 
address of the packet. Regarding the destination port, 
if an Identical destination port Is present in the routing 
table (a), the entry including the identical destination 
port is selected. If an Identical destination port is not 
present but there is an entry whose destination port is 
not specified, the entry having the wild-card destination 
port is selected. Hereinafter, this search method is re- 
ferred to as a "best-match" searching method. In Fig. 6. 
the case where the destination port is not specified (i. 
e,, is wild-card) is indicated by In Fig. 6, the entry (S, 
G, 1) indicates the output VC pointer "2," so "2" is re- 
turned as the result of the search process. 

Next, routing table (b) (Fig. 6(b)) is searched, using 
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the output VC pointer from table (a) as a key, to obtain 
an output l/F and output VC, and then a packet is trans- 
nnitted onto the obtained output VC of the obtained out- 
put l/F (S2). Since the output pointer Is "2," output IF= 
a, output VC = VC 1 in the entry of address "2*' In Fig. 6 s 
are obtained, the packet Is sent with output l/F = a and 
output VC = VC1 . When the next pointer Is sought, and 
no corresponding entry exists ("X*) (S3 NO), processing 
stops. 

Now consider a case where the packet that Is sent io 
has source S, destination G and destination port 2. 
Routing table (a) is searched in accordance with the 
flowchart of Fig. 5. None of the entries in the routing ta- 
ble of Fig. 6 corresponds exactly to (S, G, 2). However, 
In the set (S, G), there Is an entry (8, G, -) for which the ^5 
destination port is not specified, so output VC pointer 
"1" Is obtained. 

Then, the packet is sent to output IF = a, output VC 
= VCO written in the entry of address "1 ■ in routing table 
(b). No further pointer exists, so sending of the packet 20 
terminates. 

Next, a method of packet transfer at router 3 (R3) 
will be described In detail. > 

Fig. 4 shows an exemplary configuratk>n of a router 
In accordance with the principles of the present Inven- 
tion. Packets input from network l/F (24) are subjected 
to input processing by Input processing section (21 ), and 
then output processing section (22) Is consulting routing 
table (23), to send the packets to the network through 
network l/F (24). Sending Is effected in accordance with 30 
the flowchart shown In Fig. 5, which shows operation of 
output processing section (22). This operation is similar 
to that of sending node (S). Network-layer processing 
section (20) Includes Input processing section (21 ), out- 
put processing section (22) and routing table <23). The 55 
routing table in R3 Is as shown in Fig, 7. 

When a multicast packet (source S. destination G, 
destination port 1 ) is received from source S, R3 search- 
es routing table (a) (Fig. 7(a)), using (S, G, 1) as a key 
in order to transfer the packet (SI). There Is In fact an ^0 
entry (S, G. 1 ) that fully agrees with the packet, so "3," 
which Is the output VC pointer of this entry, is obtained. 
This packet Is then transferred (S2) to output l/F = b. 
output VC = VC3 written in the address "3" of routing 
table (b) (Fig. 7(b)). 45 

Continuing with Fig. 5, the next pointer Is "4' (S3 
YES), so, taking this pointer as the output VC pointer 
(S4). the packet is transferred also to output l/F = c, out- 
put VC = VC4, which Is in the entry of address "4" of 
routing table (b) (Flg.7(b)). There is no further pointer. ^0 
so sending is stopped at this point. 

When a multicast packet (source S, destination G, 
destination port 2) is received from source S, R3 search- 
es routing table (a) (Fig. 7(a)), using (S, G, 2) as a key, 
In order to transfer the packet. The result of the search 
process is that this matches an entry (S, G, -), so output 
VC pointer "1 " is obtained. The packet is sent to output 
l/F = b, output VC = VC2 pointed by address "1 " in rout- 



ing table (b) (Fig. 7(b)). As the next pointer is "2", the 
packet is sent also to output l/F = c. output VC = VC4, 
which is in the entry of address "2" of routing table (b) 
(Fig. 7(b)). Since there is no further pointer, processing 
stops at this point. 

The above description was given for the case of R3 
only, but similar operations take place In R1 and R2. 
However, since no QOS Is requested downstream of R1 
and R2, all the packets of destination address G (pack- 
ets arriving by VCO and packets arriving by VC1 ) are 
transferred by one "best effort" VC. 

The characteristic features of this example may be 
summarized as follows. In order to transfer packets to 
a plurality of destination nodes (HI, H3, H4, H5, H7) in 
multicast communication, a plurality of virtual connec- 
tions (VCO and VC1, or, VC2 and VC3) to a plurality of 
second nodes (R1 and R2 and R3, or, H4 and H5) are 
set up from a first node (S or R3). Then, the first node 
transmits packets (S, G, 1) belonging to a specified flow 
onto some (VC1 or VC3) of the plurality of virtual con- 
nections; and transmits packets destined for the desti- 
nation nodes other than those belonging to the specified 
flow onto other (VCO or VC2) of the plurality of virtual 
connections, so that all packets to the destination nodes 
can be received without duplication by the respective 
second nodes from the plurality of virtual connections. 

The virtual connection (VC1 or VC3), whereby 
packets belonging to a flow for which a specified QOS 
is to be provided are transferred, is set up when the 
specified QOS Is requested for this flow (S, G. 1 ) ) by at 
least one of the plurality of destination nodes (for exam- 
ple, H5). 

The virtual connection (VC1 or VC3) can be set up 
when a packet of a specified protocol (either a packet 
to a secorKJ node or a packet from the second node ) is 
detected and the protocol is instructing use of a virtual 
connection separate from the currently used virtual con- 
nection (VCO or VC2) in order to transfer packets to one 
of the plurality of destination nodes (for example, H5). 
In this case also, it can be said that this separate virtual 
connection (VC1 or VC3) serves to transfer packets with 
a specified QOS and that this destination node (H5) has 
requested the specified QOS for that packet flow. 

If no destination node has requested any specified 
QOS for the aforesaid flow in a logical network (subnet 
E) downstream of the second node (R3), the second 
node (R3) sends both (S, G. -) packets belonging to the 
aforesaid flow and other packets destined to the desti- 
nation nodes received from the first node onto one vir- 
tual connection (VC4) to a next-hop node. 

Consequently, all the packets can be reliably trans- 
ferred to each destination node without duplication while 
satisfying the QOS for the specified flow requested by 
one or more of the destination nodes. 

(Embodiment 1 , Specific example 2) 

In this specific example, multicast packets are 
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transferred by setting up a new VC toward a node that 
has requested QOS to transfer the flow for which CXDS 
has been requested, while setting up another new VC 
toward a node that has not requested QOS to transfer 
the aforesaid flow. 

Fig. 8 is a diagram of the set-up of VCs after H5 has 
requested QOS for packets (S, G, 1) and this request 
has arrived at S through R3. VC2 and VCS are VCs for 
transferring packets (S G, 1) with the requested QOS. 
VC 1 and VC4 are VCs for transferring packets (S, G, 
1) to nodes other than those which have requested 
QOS. VCO and VCS are VCs for transferring packets of 
destination address G except the packets (S, G, 1 ) VC6 
is a VC for transferring packets of destination address G . 

By setting up a configuration as above, packets can 
be distributed to'kll nodes participating in a group with- 
out duplication of identical packets. 

The method of packet transfer shown in Fig. 5 re- 
ferred to in specific example 1 is also used in this exam- 
ple. The routing table of S is shown in Fig. 9 and the 
routing table of R3 is shown in Fig. 1 0, S and R3 operate 
as in the case of specific example 1 regarding packet 
forwarding, but the results are different in accordance 
with the contents of routing tables. 

The characteristk; features of this example may be 
summarized as follows. In order to perform packet trans- 
fer to a plurality of destination nodes (HI, H3, H4, H5, 
H7) in multicast communication, a plurality of virtual con- 
nections (VCO and VC 1 and VG2, or. VC3 and VC4 and 
VCS) are set up to at least one of a plurality of second 
nodes (R1. R2, R3 or H4, H5) from a first node (S or 
R3). The QOS requested for the packets to be trans- 
ferred through VC2 and VCS is different from that of VCO 
and VC3, or VC1 and VC4. 

Then, the first node transmits packets (S, G, 1) be- 
longing to a specified flow onto some (VC1 and VC2, or. 
VC4 and VCS) of the plurality of virtual connections; and 
transmits packets destined for the destination nodes 
other than those betonging to the specified flow onto oth- 
er (VCO or VCS) of the plurality of virtual connections, 
so that the entire packets to the destination nodes can 
be received without duplication by the respective sec- 
ond nodes from at least two of the plurality of virtual con- 
nections. 

Other characteristic features in this example are 
similar to specific example 1 . 

(Embodiment 1 , Specific example 3) 

In this specific example, two new VCs are set up 
toward a node that has requested QOS while a leaf to 
that node is removed from an existing "best-effort" VC. 
One of the newly set up VCS transfers a flow for which 
QOS has been requested, while the other transfers 
packets other than the aforesaid flow. 

Fig. 11 is a diagram showing the set-up of VCs after 
HS has requested QOS of packets (S, G, 1 ) ) and this 
request has arrived at S through R3. VC1 and VC4 are 



new VCs for transferring packets for which QOS has not 
been requested, while VC2 and VCS are other new VCs 
for transferring packets for which QOS has been re- 
quested. The leaf to R3 is deleted from "best-effort" 
5 VCO, and the leaf to H5 is deleted from "best-effort" VCS. 
The method of packet transfer shown in Fig. 5 re- 
ferred to in specific example 1 is also used in thjs exam- 
ple. The routing table of S is shown in Fig. 12 and the 
routing table of R3 is shown in Fig. 13. S and R3 operate 

10 as in the case of specific example I regarding packet 
forwarding, but the results are different in accordance 
with the contents of routing tables. 

The characteristic features of this example may be 
summarized as follows. In order to transfer packets to 

'5 a plurality of destination nodes (HI, H3, H4, H5, H7) in 
multicast communication, there are set up from a first 
node (8 or R3), a plurality of first virtual connections 
(VC1 and VC2. or, VC4 and VCS) to a specified one (R3 
or H5) of a plurality of second nodes (R1 and R2 and 

^o R3, or, H4 and H5), and a second virtual connection 
(VCO or VCS) to second nodes other than the specified 
node. The QOS request for packets transferred through 
VC2 and VCS is different from that of packets trans- 
ferred through VCO and VCS, or VC1 and VC4. 

2S Then, the first node transits packets (S, G, 1) be- 
longing to a specified flow onto some (VC2 or VCS) of 
the plurality, of first virtual connections and the second 
virtual connection (VCO or VCS); and transmits packets 
destined for the destination nodes other than those be- 

30 longing to the specified flow onto other (VC1 or VC4) of 
the plurality of first virtual connections and the second 
virtual connection (VCO or VCS), so that all packets to 
the destination nodes can be received without duplica- 
tion by the respective second nodes from at leasi one 

3S of the plurality of virtual connections. Packets (S. G, -) 
flow onto VCO and VCS. Destination node (HS) that has 
requested specific QOS for (S, G, 1 ), or a node (RS) 
which packets destined for this destinatran have to pass 
through, is the specified node referred to above. 

40 Other characteristic features in this example are 
similar to specific example 1 . 

(Embodiment 2) 

45 The embodiment shown in Figs. 1 4 through 20 pro- 
vides a scheme of implementing multicast packet trans- 
fer with different QOS in whteh, although duplicated 
packets are received at each node, packets are selec- 
tively deleted to avoid processing both of the duplicated 
so packets. 

Initially, VCs are set up as in Fig. 1 in the same way 
as in embodiment 1 when only "best-effort" sen/ice is 
provided. 

Now consider a case where a receiving host HS re- 
55 quests QOS for multicast packets of source S, destina- 
tion address G, and destination port 1 (hereinafter re- 
ferred to as (S, G, 1 )) and H5 transmits the QOS request 
using RSVP. R3 sets up VCS, which is a point-multipoint 
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VC satisfying the QOS, as shown in Fig. 14, and then 
sends packets (S, G, 1 ) by this VC. R3 also notifies H5 
that packets (S, G, 1 ) are being sent through VC3. Since 
R3 is still sending packets of destination address G 
through VC2, H5 is receiving packets (S, G. 1)) from 
both VC2 and VC3. However, duplicated processing of 
packets is avoided by discarding the packets (S, G, 1 ) ) 
arriving fronn VG2. 

R3 makes a QOS request to source S, and then 
VC1 1 is set up in a similar way as VC3. R3 prevents 
duplicated transfer of packets by discarding packets (S, 
G, 1) arriving from VGO, by being notified that packets 
(S, G, 1) are flowing onto VC3 from S. 

The operations of S. R3 and H5 when sending pack- 
ets (S, G.I)) and when sending packets (S, G. 2) will 
now be described in detail. 

The configuration of sending host S is shown in Fig. 
3, and the output procedure of output processing unit 
(11) is in accordance with the flowchart of Fig. 15. The 
routing table of S is shown in Fig. 16. 

The configuration of router R3 is shown in Fig. 17. 
The difference between the router of Fig. 17 and the 
router of embodiment 1 (Fig. 4) is that packet discarding 
table (25) used by input processing section (21 ) is add- 
ed. The sending sequence in output processing section 
(22) is in accordance with the flowchart of Fig. 15. The 
routing table of R3 is shown in Fig. 18, and the packet 
discarding table of R3 is shown in Fig. 19. 

The configuration of receiving host H5 is shown in 
Fig. 20- Packets input from network l/F (34) are discard- 
ed if they are duplicated. This is achieved by input 
processing section (31), referring to packet discarding 
table (35). the discarding packet table of H5 is also 
shown in Fig. 19. 

When S sends a packet (S, G, 1), it first of all sets 
a pointer at the head of routing table (a) of Fig. 16 (S21 
in Fig. 15). Next, it searches routing table (a) (Fig. 16 
(a)) using (S, G. 1 ) as a key starting from the entry in- 
dicated by this pointer (S22) and stepping through the 
table until one entry is selected or there are no more 
entries to search. In other words, entries whose source 
and destination addresses match with those of the pack- 
et are extracted, and then, anrong the extracted entries, 
one or more entries are selected as far as its destination 
port matches with that of the packet. Namely, a method 
of non-'best match" searching is employed in this em- 
tjodiment. 

Comparing at the first row of routing table (a) (Fig. 
16(a)), it is found that the entry (S, G, -) matches with 
(S, G, 1 ), so output VC pointer "1 • is obtained. The pack- 
et is sent onto the output VC indicated by the output 
pointer (S23), in this example, onto output l/F = a, output 
VC = VCO indicated by address "1 " in routing table(b) 
(Fig.1 6(b)). Routing table (b) (Fig. 16(b)) yields no fur- 
ther pointer, so the processing of S23 is terminated. 

Then, the pointer shifts to the next entry, in this ex- 
ample, to the second row, of routing table (a)( Fig. 16 
(a)) (S24), and routing table (a) (Fig, 16(a)) is further 



searched based on (S, G. 1 ) (S22). On searching from 
the second row. it is found that the entry (S, G, 1 ) match- 
es with (S. G, 1 ). so output pointer "2" is obtained. The 
packet is transmitted onto output l/F = a, output VC - 

5 VC1 of address "2" of routing table (b) (Fig. 1 6(b)) (S23). 
Since there is no further pointer in routing table (b) (Fig. 
16(b)), the pointer shifts to the third row of routing table 
(a) (Fig. 16(a)) (S24), whereupon it is found that search- 
ing of all the entries has been completed in S22, so 

10 transmission of the packet terminates. 

R3 receives double packets (S, G, 1) ) from VCO 
and VC 1 . The received packets, together with the virtual 
connection identifier received from the network l/F (24), 
are handed over to network-layer processing section 

IS (20). Input processing section (21), when the packets 
are handed over, checks by searching packet discarding 
table (25) of Fig, 1 9 to find out whether they are packets 
that should be discarded. 

The set (source address, destination address, des- 

20 tination port) of the received packet Js checked against 
the packet discarding table. If there is a matching entry, 
only a packet coming from the input l/F, input VC given 
in this table is allowed through. A packet having (source 
address, destination address, destination port) and 

25 coming from another VC than the written VC is discard- 
ed. 

Packets (S, G, 1) received from VCO and Vp1 
match the entry in the packet discarding table of Fig. J 9. 
Therefore, only packets received from input l/F = a. input 

30 VC = VC1 , as indicated in the table, are allowed through. 
The packets (S, G, 1 ) coming from VCO are discarded. 
The packets coming from VC1 are subjected to the fol- 
lowing packet transfer processing. 

This entry in the packet discarding table is created 

35 when R3 is notified that packets (S, G, 1) are being 
transmitted through VC1 from S. 

R3 transfers a packet in accordance with the flow- 
chart of Fig. 1 5 in a similar way as S. using the routing 
table shown in Fig. 1 8. The pointer shifts to the head of 

40 routing table (a) (pig. 18(a)) (S21), and R3 checks to 
examine whether the first row of routing table (a) (Fig. 
18(a)) matches (S. G, 1 ). Since the first row is (S, G, -) 
(i.e., matches (S. G, 1)), output VC pointer "1" is ob- 
tained (S22). So. the packet (S, G, 1) ) is sent onto out- 

45 put l/F = b, output VC = VG2 of address "1 " of routing 
table (b) (Fig. 18(b)). 

Since the next pointer indicates "2," the packet (S, 
G, 1 ) is sent also onto output l/F = c, output VC = VC4 
of address "2" of routing table (b) (Fig. 18(b))(S23). 

so Since there is no further pointer in routing table (b) 
(Fig. ie(b)), the pointer of routing table (a) (Fig. 18(a)) 
shifts to the second row (S24). R3 checks to see wheth- 
er the entry there matches (S. G, 1). Since there is an 
entry (S, G, 1), output VC pointer "3" is obtained (822). 

55 The packet (S, G, 1) is sent onto output l/F = b, output 
VC = VC3of address "3" of routing table (b) (Fig. 18(b)) 
(S23). Since there is no subsequent pointer in routing 
table (b) (Fig. 18(b)), the pointerof routing table (a) (Fig. 
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18(a)) shifts to the third row (S24). and then it is found 
that all of routing table (a) (Fig. 18(a)) has been 
searched, so transfer of the packet terminates. 

H5 receives duplicated packets (S. G, 1 ) ) from VC2 
and VC3. Just as in the case of R3, by referring to the 
packet discarding table, it Is decided whether the re- 
ceived packet is to be discarded or not. The packets (S, 
G, 1 ) ) coming from VC2 are discarded, while the pack- 
ets (S, G, 1) coming from VC3 are not discarded and 
are subjected to processing at the network or higher lay- 
er In this way. H5 can avoid processing both of the du- 
plicated packets. 

Now, the procedure for transfer of packets (S, G, 2) 
is described below. S searches routing table (a) of Fig. 
16, using (S, G, 2) as a key. Since the entry (S, G, -) is 
matched, output VC pointer "1 " is obtained. The packets 
are transmitted onto output l/F = a, output VC = VCO of 
address "1 " of routing table (b) of Fig. 16. Since there is 
no subsequent pointer In routing table (b). next search- 
ing is performed from the next entry of routing table (a), 
using (8, 2) as a key. There is no corresponding entry, 
so transmission of the packet is thereupon terminated. 

R3 finds that the received packets (8, G. 2) are not 
to be discarded, referring to the packet discarding table, 
and then the packets are transferred through output l/F 
= b, output VC = VC2 and output i/F ~ c, output VC = 
VC4, in accordance with the operation described above. 

Alternatively, output processing of packets in this 
embodiment can be performed by the method of specific 
example 2 of embodiment 3 that will be described later 
Specifically, the flowchart of Fig. 5 ("best-match" 
searching method) is employed as the packet sending 
procedure, while the next pointer of address "1 " of rout- 
ing table (b) of Fig. 1 6 is set to "S" and an entry of [output 
l/F = a, output VC = VC1 , next pointer = "X"] is added 
at address "S". 

An advantage of this embodiment is that the set-up 
procedure involved in changing a condition from Fig. 1 
(where the QOS is only "best-effort") to Fig. 14 (where 
new VCs are set up corresponding to a QOS request) 
can be simpler than that of embodiment 1 . Also, the 
number of VCs to be set up can be small, since only 
VCs along the path from the source to the destination 
that requested QOS are to be newly set up. 

The characteristic features of this embodiment may 
be summarized as follows. In order to transfer packets 
to a plurality of destination nodes (HI . H3, H4. H5, H7) 
in multicast communication, there are set up from a first 
node (S or R3), a first virtual connection (VCO or VC2) 
to a plurality of second nodes (Rl and R2 and R3, or, 
H4 and H5), and a second virtual connection (VC1 or 
VC3) to at least a specified one (R3 or H5) of the plurality 
of second nodes. The first and second virtual connec- 
tions are different in the QOS requests. 

Then, the first node transmits packets such that the 
respective second nodes receive packets (S, G, -) des- 
tined for the destination nodes by the first virtual con- 
nection and that at least the specified node receives 



packets (S. G, 1) belonging to a specified flow not only 
by the first virtual connection but also by the second vir- 
tual connection. 

The specified node (R3 or H5) selects packets (S. 

5 G, 1) belonging to the specified flow from the packets 
(S, G, -) received by the first virtual connection (VCO or 
VC2), and discards the selected packets. 

The second virtual connection (VCI or VCS) Is set 
up when a specified QOS is requested for the aforesaid 

10 flow by at least one (for example, H5) of the plurality of 
destination nodes. The specified node can be either the 
destination node (H5) that requested this QOS, or a 
node (R3 ) through which the packets to the specified 
destination node pass. 

IS The specified node (R3 or H5), on receiving dupli- 
cated packets belonging to the aforesaid flow, identifies 
a flow to which the packets that are to be received by 
the second virtual connection belong by using the pack- 
et discarding table, and selects packets belonging to the 

20 identified flow from the packets received by the first vir- 
tual connection to discard them. Packets which are not 
discarded ((S, G, 1) received by VCI or VCS. and (S. 
G, -) excluding (S, G, 1) received by VCO or VC2) are 
subjected to the network- layer processing for transfer to 

2S the next-hop node (i.e., analysis of a destination ad- 
dress contained in the packet) or for an application at a 
layer higher than the network layer. 

If the specified node (R3) is not yet a destination 
node, and If the packets that have been processed at 

30 the network layer and are destined for the destination 
node do not belong to the specified flow, they are trans- 
ferred onto VC2; if the above packets betong to the 
specified flow, they are transferred onto VC2 and VC3. 
That is. packets (S, G, 1 ) received by VCI and packets 

3S (S, G, -) except(S. G, 1) received by VCO are transferred 
through VC2, and packets (S, G, 1 ) received by VCI are 
transferred through VCS. VCI is dedicated to the spec- 
ified flow and VCS Is likewise dedicated to the specified 
flow. 

40 It is possible to set up VCI or VC3 also to a second 
node other than the specified node. In this case, the oth- 
er second node (Rl , Fi2 or H4) for which the second 
virtual connection operates in a similar way as the spec- 
ified node referred to above. If there is no virtual con- 

46 nection dedicated to the specified flow downstream of 
the other second node, the other second node can 
transfer all the packets that were not discarded onto one 
"best-effort" virtual connection present on the down- 
stream side. 

so Alternatively, the router in embodiment 2 may be 
constructed as follows. In order to determine an output 
VC for packets to be transferred through the VC dedi- 
cated to the specified flow the router refers to a datalin k- 
layer (e.g., ATM) routing table, instead of performing the 

ss network-layer processing by referring to the routing ta- 
ble based on the destination address. 

The ATM-level routing table in R3 stores infonmatlon 
specifying that packets from VCI are to be transferred 
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onto only VC3, which is the VC dedicated to the speci- 
fied flow to the next-hop node. The packets from VC1 
are therefore transferred onto VC3 without being trans- 
ferred onto VC2. It is possible to process the packets 
from VC1 at the network layer only regarding other 
processing than for determining the output VC based on 
the destination address. 

The network-layer-level routing table in R3 stores 
infonmation specifying that packets of destination ad- 
dress G are to be transferred onto only VC2. Conse- 
quently, packets from VCO are transferred onto VC2 
without being transferred to VC3. 

In this way also, router R3 can prevent the double 
packets (S, G. 1 ) from being further duplicated by trans- 
fer onto both VC2 and VC3, even without discarding 
packets. However in this case also, the destination node 
discards packets (S, G, 1 ) coming from VC2. 

Consequently, according to this embodiment, the 
duplicated packets can be transferred to next-hop node 
without further inadequate duplication, and an spurious 
operation of the application software in the receiving 
node can be prevented. 

(Embodiment 3) 

This embodiment provides a scheme (specific ex- 
amples 1 through 3) of implementing multicast packet 
transfer with different QOS requests by using the CSR 
technology. 

CSR is an exemplary router having a function for 
transferring packets at a layer lower than the network 
layer (e.g. in ATM cell units). CSR has an ATM switch 
function in addition to a function for transferring packets 
in IP packet units, in order to achieve high throughput 
and low latency packet transfer for internetwork environ- 
ment. 

A simple description of the operation of a CSR will 
now be given with reference to Fig. 21. It is considered 
a case where packets are transferred from XI through 
the CSR to Y1. 

In order to perfomn IP packet transfer (i.e., hop-by- 
hop transfer), packets are sent onto an ATM connection, 
which is set up for transfer of packets of various desti- 
nations from X. 1 to the CSR. This ATM connection will 
be called a default VC. The CSR detenmines a next-hop 
node by examining the destination of the IP packet. This 
analysis of the destination address is performed by IP 
processing. In this case, the next-hop node Is Y. 1, so 
packets are transferred to Y 1 by sending the packets 
onto a default VC. 

In order to perfonm ATM cell transfer, an ATM con- 
nection from X. 1 to the CSR dedicated to transfer of 
packets to Y 1 and an ATM connection from the CSR to 
Y 1 dedicated to transfer of packets to Y. 1 are set up. 
These ATM connections will be called dedicated VCs. 
The CSR sets up the ATM switch function in the CSR 
so as to transfer ATM cells from one dedicated VC to 
the other dedicated VC, bypassing the IP processing. 



20 

That is, the CSR stores the correspondence relationship 
between a VPIA/CI at the receiving port of the dedicated 
VC from X. 1 to the CSR and a VPIA/CI at the sending 
port of the dedicated VC from the CSR to Y 1 in a routing 

s table at the ATM level. In this way, a bypass pipe (i.e., 
a cut-through connection) can be formed that directly 
links the dedicated VCs belonging to different logical 
networks (e.g. IP subnets). 

When X. 1 sends packets to Y. 1 , the packets are 

10 transferred from X. 1 to the CSR through the dedicated 
VC for Y 1 . Then the CSR transfers the packets through 
the dedicated VC for Y 1 from the CSR to Y 1 . while the 
packets are still in the form of ATM cells, by referring to 
the ATM-level routing table. 

is In the above example, packet transfer by directly 
linking the dedicated VCs is transferring packets in ATM 
cell units. However, the packet transfer through the di- 
rectly linked dedicated VCs may also be transferring 
packets In AAL (ATM Adaptation Layer) trarhe units. In 

20 this case also, the AAL frame transfer is performed by 
referring to a routing table at ATM level. In either case, 
packets are transferred without network-layer process- 
ing. 

Also, packet transfer through the directly linked 
25 dedicated VCs can be transferring packets from a ded- 
icated VC, to which other network-layer processing (e. 
g., in the case of IP, decrementation of TTL (Tinrie to 
Live), calculation of checksum, etc.) than determinatbn 
of output VC based on the network-layer destination ad- 
30 dress with reference to an IP-level routing table Is ap- 
plied, onto a dedicated VC to the next-hop node. Injhis 
case too, the packet transfer can be performed by de- 
termining the output VC with reference to an ATM-level 
routing table. In this case, packets are transferred, with 
3S only some of the network-layer processing, without des- 
tination analysis at the network layer. 

The embodiments according to the present inven- 
tion, which will be described below, can be applied to 
any of the configurations using a CSR described above. 
40 ' Fig. 22 shows an example of a CSR configuration. 
IP processing section 301 performs network-layer 
processing; AAL processing section 302 converts ATM 
cells into AAL frames; and ATM switch 303 performs cell 
transfer. By copying input cells ATM switch 303 can out- 
45 put cells to a plurality of output l/Fs. 

The upper layer processing section 31 0 includes IP 
processing section 301 , AAL processing section 302, in- 
put VC V. flow table 311 and managing section 309. IP 
processing section 301 comprises input processing see- 
so tion 307. output processing section 306, and IP routing 
table 304. while ATM switch 303 comprises ATM routing 
table 305. The input VC v. flow table 311 stores informa- 
tion indicating a flow that are to be input from a given 
VC. Managing section 309 refers to, or creates an entry 
ss in, the IP routing table and the ATM routing table in ac- 
cordance with the input VC v. flow table. 

In the above example, the network-layer processing 
was described as being performed by the IP processing 
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section. The network-layer processing, however, can be 
performed In a similar way also In a case of another net- 
work-layer protocol (e.g., IPX). 

(Embodiment 3, Specific example 1) 

The operation of the CSR in the case where the 
CSR does not receive the duplicated packets, as in em- 
bodiment 1, will be described. Packets can flow only in 
the directly linked VCs when the input VC and the output 
VC are directly linked by the CSR. Thus, packets do not 
reach receiving parties that are not directly linked, even 
though these are participating in the multicast commu- 
nication. This specific example provides a method of 
overcoming this problem while the CSR transfers re- 
ceived packets downstream such that packets are not 
duplicated. 

A case where the router R3 of Fig. 1 is a CSR will 
now be described. Fig. 23 is a view of VC set-up where 
R3 is placed at the center. The arrows of Fig. 23 are for 
purposes of illustration only, to show communication 
flow from subnet A. Information may also flow from the 
other subnets. 

Packets arrive at the CSR from subnet A through 
three VCs: VCD, VC1 and VC2. These VCs are set up 
so as to allow the following packets to flow, On VC 1 . 
packets of source address S, destination address G1, 
and destination port 1 flow. On VCD, packets of source 
address S, destination address G1, but of destination 
port other than 1 , flow. On VC2, packets of source ad- 
dress S and destination address G2 flow. Hereinafter, 
the set consisting of source address S, destination ad- 
dress G1 and destination port 1 is represented as (S, G 
1.1). 

In this example, nodes participating in destination 
address G and G2 are present on subnet D and subnet 
E. This means that packets received from subnet A must 
be sent to subnet D and subnet E. Now consider a case 
where participants of subnet D have requested a spec- 
ified QOS for the flow of (S, G1 , 1) but the participants 
of subnet E have not made any request in regard to this 
flow. 

ATM cells arriving from VCD are handed over to the 
upper-layer processing section, to assemble cells into 
packets and to determine an output l/F. These packets 
are divided Into cells, and then sent onto VC3 and VC6. 
Cells arriving from VC1 are transferred onto directly 
linked VC4, and also handed over to the upper-layer 
processing section to be sent onto VC6. Cells received 
from VC2 are transferred onto directly linked VCS and 
VC7. 

That is, If a direct link is formed to only some (not 
all) of the receiving parties, the cells are copied by the 
ATM switch to be handed over to the upper-layer 
processing section, tn this way, packets can be sent to 
participants for whom a direct linked is not formed. 

The above operation will be described in detail, with 
reference to flowcharts of Fig. 24 and Fig. 25, the IP 



routing table of Fig. 27 (304 in Fig. 22), and the ATM 
routing table of Fig. 26 (305 of Fig. 22). 

When the packets (S, G1 , 2) from VCO arrive as 
ATM celts, the ATM switch outputs cells in accordance 
5 with the flowchart of Fig. 24. First of all, ATM routing ta- 
ble (a) of Fig. 26 is searched (S41) to obtain an output 
VC pointer, using the input l/F and input VC as a key 

VCO Is input l/F = a. input VC = VCO, so the output 
VC pointer is "1 The entry of address "1 " In ATM routing 
10 table (b) of Fig. 26 is found based on the output VC point- 
er. The entry indicates output l/F - upper layer, so the 
cells are handed over to the upper-layer processing sec- 
tion (842). Since there is no further pointer in ATM rout- 
ing table (b) of Fig. 26 (S43: NO), processing terminates 
IS at this point. 

The cells that are handed over to the upper-fayer 
processing section are assembled into packets. These 
packets are transferred in accordance with the flowchart 
of Fig. 25. 

20 When a packet (S. G1, 2) arrives. IP routing table 
(a) of Fig. 27 is searched by the "best-match" method 
(S45) using (S, G1 , 2) as a key. Matching is achieved at 
the entry (S, G1 , -), so output VC pointer "1 " is obtained. 
Using output VC pointer "1 " as the address, the entry of 

2$ output l/F = b, output VC = VC3, direct-link = no, and 
next-pointer "2" Is found in IP routing table (b) of Fig. 27. 

Since direct-link = no (S46: No), the packet is sent 
onto output l/F = b, output VC = VC3 (S47). 

Since the next pointer Is "2" (S48), by looking at ad- 

30 dress "2" of IP routing table (b) of Fig. 27 (S49), the same 
operation as above is performed. Namely, the packet is 
sent also onto output l/F = c, output VC = VC6(S47). 
Since the next pointer Is "X," packet transfer is complet- 
ed. 

35 Now, a case where packets (S, G1 , 1 ) are received 
from VC1 Is described below. The methods of transfer 
at the ATM switch and of transfer in the upper-layer 
processing section are as described above regarding 
VCO. When cells arrive from VC1, by referring to the 

40 ATM routing table of Fig. 26, the ATM switch sends the 
packet to the upper layer as well as onto output l/F = b. 
output VC = VC4. This operation makes it possible to 
ensure that packets will not fail to reach even partk;t- 
pants for whom the VCs are not directly linked, by cop- 

4S ying cells to be transferred through the directly linked 
VC and by handing the cells over to the upper layer. 

When the upper-layer processing section searches 
IP routing table (a) of Fig. 27 by "best-match" using (S, 
G1 ,1) as a key, output VC pointer "3" is obtained and 

so so, from IP routing table (b) of Fig. 27. the entry of output 
l/F = b, output VC = VC4, next-pointer "4", and direct- 
link = yes is found. 

Since direct-link = yes (S46: Yes), the next pointer 
•4" is tried (S48) without outputting the packet to VC4. 

ss Then, the entry of output l/F = c, output VC = VC6, and 
direct link = no is found, so the packet is sent onto VC6 
(S47). As a result, packets (S, G1, 1) will be sent even 
to participants (corresponding to VC6) that are not di- 
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rectty linked. 

If cells arrives from VC2, the cells are directly trans- 
ferred output l/F = b, output VC=VC5 and output UF = 
c. output VC = VC7, by referring only to the ATM routing 
tableof Fig.26. Inthlscase, packets do not pass through 
the upper-layer processing section. This is because 
there is no participant node not directly linked regarding 
packets of source address S, destination address G2 
(there is no need to copy the cells in order to give the 
packets to the upper layer). 

According to the above method, the direct linking of 
dedicated VCs in multicast packet transfer can be prac- 
ticed such that the packets can reliably be sent to all the 
participants of multicast group. 

Implementing the above method may require deter- 
mining whether the ATM switch is to copy the cells and 
hand them over to the upper-layer processing section. 
This is detemriined by managing section 309 of Fig. 22 
referring to IP routing table 304 of Fig. 27 and input VC 
V, flow table 311 of Fig. 28. to set up ATM routing table 
305. 

Managing section 309 can identify the flow on an 
input VC, with reference to the input VC v. flow table. If, 
on looking up this flow in the IP routing table, it is found 
that none of its output VCs are directly linked, or, alter- 
natively, that all of its output VCs are directly linked, it is 
determined that there is no need for the ATM switch to 
copy the cells for the upper-layer processing section. It 
is determined that there is a need for the ATM switch to 
copy the cells for the upper-layer processing section if 
some of the output VCs are directly linked while others 
are not directly linked. The managing section sets up 
the ATM routing table on the basis of this decision. 

Specifically, it can be seen from Fig. 28 that packets 
(S, G1, 1) are flowing in VC1. Searching the tables of 
Fig. 27 using (S, G1 , 1 ) as a key, it is found from IP rout- 
ing table (b) that there is one directly linked VC (VC4) 
and one VC that is not directly linked (VC6). It is there- 
fore detemnined that the ATM switch needs to perform 
copying regarding VC 1 to hand the cells over to the up- 
per-layer processing section. 

It can be seen from Fig. 28 that packets (S. G2, -) 
are flowing in VC2, so, using this as a key to search the 
tables of Fig. 27, it is found that both the VCs (VCS and 
VC7) are directly linked. It is therefore determined that 
it is not necessary tor cells to be copied to be handed 
over to the upper-layer processing section. 

Using information obtained in this way, ATM routing 
table of Fig. 26 is set up. In the ATM routing table, VCO 
is the default VC, so this is simply to be handed over to 
the upper layer The correspondence relationship such 
that VC 1 is directly linked to VC4 is stored, and the cor- 
respondence relationship such that VC2 is directly 
linked to VC5 and VC7 is stored. When, regarding VC1 , 
it is found that there is need to copy cells for the upper 
layer the next pointer of VC4 is set and the upper layer 
is written in the entry indicated by the next pointer. 

Referring to Fig. 23, if there is a node in subnet F 



(not shown) that participates also in destination address 
G2 and VCS for that node is not directly linked with VC2, 
packets (S, G2, -) can be transferred onto VCS also by 
handing them over to the upper layer by copying cells 
5 from VC2 in the same way as above. 

The characteristic features of this example may be 
summarized as follows. In order to transfer packets to 
a plurality of destination nodes in multicast communica- 
tion, a router transfers packets received from a first node 
10 (subnet A) belonging to one logical network to a plurality 
of second nodes (subnets D and E) belonging toanother 
logical network. The router stores a correspondence re- 
lationship between a flrst virtual connection (VC1) that 
is capable of receiving packets from the first node and 
IS a second virtual connection (VC4) that is capable of 
sending packets to a specified node (subnet D) of the 
plurality of second nodes, and transfers packets in ac- 
cordance with this correspondence relationship, by- 
passing a network-layer processing (i.e., transfers pack- 
20 ets by direct linking). Also, if it is determined that one or 
more (subnet E) of the plurality of second nodes other 
than the specified node will receive none or not all of the 
packets destined for the destination nodes due to the 
direct linking, the router transfers packets received from 
25 the first virtual connection (VC1) to the aforesaid node 
(subnet E) other than the specified node by copying the 
received packets for the network-layer processing. 

More specifically, it is determined that the aforesaid 
node will not receive packets, when apart from the sec- 
30 ond virtual connection (VC4) whose corirespondence re- 
lationship with the first virtual connection (VC1 ) is stored 
corresponding to a packet flow (S, G1 , 1 ) to be received 
from the first virtual connection, there Is a third virtual 
connection (VC6) corresponding to that packet flow 
35 whose correspondence relationship with the flrst virtual 
connection is not stored. 

In contrast, the above determination is not effected, 
when there is no third virtual connection other than the 
second virtual connections (VCS and VC7) whose cor- 
40 respondence relationships with the flrst virtual connec- 
tion (VC2) are stored corresponding to a packet flow (S, 
G2, -) to be received from the flrst virtual connection. 

Consequently, the received packets are copied if 
necessary, one copy being transferred through the di- 
45 rect link toward some of the destination nodes while the 
other copy is handed over to the network layer to be 
transferred toward other of the destination nodes, and 
thus packets can be received by all the nodes partici- 
pating in the multicast group, 

so 

(Embodiment 3, Specific example 2) 

In this specific example, the operation of the CSR 
in the case where the CSR receives the duplicated pack- 
55 ets, as in embodiment 2, but eliminates the problem of 
chained duplication while ensuring that all the partici- 
pants will not fail to receive the multicast packets, will 
be described. 
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Fig. 29 shows another exemplary CSR configura- 
tion. The difference from Fig. 22 is that packet discard- 
ing table 308 is added in IP processing section 301. In- 
put processing section 307 checks the packet discard- 
ing table to avoid duplicated processing. 

A case where the router R3 of Fig. 1 is a CSR will 
be described. Fig. 30 is a view of VC set-up where R3 
is placed at the center. The l/F of the ATM switch with 
subnet A is called a, the l/F with subnet B is called b, 
and the l/F with subnet C is called c. The IT of the ATM 
switch with the upper-layer processing section is called 
"upper layer". 

The ATM routing table of R3 is shown in Fig. 31 , the 
IP routing table is shown in Fig. 32, and the packet dis- 
carding table is shown in Fig. 33. 

Now consider a case where packets of destination 
address G are transferred from VCO (default VC) and 
packets (S, G, 1) are transferred from VC1 (dedicated 
VC). 

When cells of packets (S, G. 1) arrived from VCO, 
these cells are handed over to the upper layer through 
VCO by operation of the ATM switch in accordance with 
the flowchart of Fig. 24, referring to the ATM routing ta- 
ble of Fig. 31 , and assembled into packets by the upper- 
layer processing section. Input processing section 307 
of the upper-layer processing section decides whether 
or not packets (S, G, 1 ) are to be discarded by referring 
to the packet discarding table of Fig. 33. The packet dis- 
carding table instructs that packets (S, G, 1 ) whose input 
VC is other than VC are to be discarded. These packets 
are therefore discarded and processing is terminated. 

When cells of packets (S, G, 2) have arrived from 
VCO, these cells are handed over to the upper-layer 
processing section, as described above, and the input 
processing section checks the packet discarding table. 
The packet discarding table contains no entry for (S, G, 
2). so these packets are not discarded. 

In order to output these packets, the packet output 
processing section operates, referring to the IP routing 
table of Fig. 32. This output processing is in accordance 
with the flowchart shown in Fig. 6. It can be seen by 
searching the IP routing table by "best-match" that these 
packets are to be output to output l/F = "upper layer", 
output VC = VC2 and VC4. 

After these packets are divided into cells and output 
onto these VCs, the ATM switch transfers the cells from 
VC2 onto output l/F = b. output VC = VC2, and transfers 
the cells from VC4 onto output l/F = c, output VC = VC4, 
in accordance with the flowchart of Fig. 24, referring to 
the ATM routing tables of Fig. 31 . 

When cells of packets (S, G, 1) arrived from VC1, 
the ATM switch transfers these cells onto VC3 directly, 
and also copies these cells to hand the copied cells over 
to the upper-layer processing section, in accordance 
with the flowchart of Fig. 24, referring to the ATM routing 
table of Fig. 31 . 

Then, the input processing section searches the 
packet discarding table using (S, G. 1) as key The entry 



that is found states that only packets whose input VC is 
other than VC 1 are to be discarded, so these packets 
are not discarded. These packets are therefore output 
by the output processing section referring to the IP rout- 
5 ing table of Fig. 32. This output method is as was de- 
scribed in the case where packets (S, G, 2) were input 
from VCO. 

In this specific example, when a direct link is 
formed, cells arriving from the upstream dedicated VC 
10 (VC1) are transferred onto the directly linked down- 
stream dedicated VC (VC3), and also copied by the ATM 
switch so as to be handed over to the upper layer (for 
transfer to VC2 and VC4). In a case where cells arriving 
from an upstream VC which are not directly linked with 
IS a downstream VC, these cells are handed over as nor- 
mally hop-by-hop transfer to the upper layer (In this 
case, cells from VC1 are transferred onto VC2, VC3and 
VC4 by ATM and IP routing tables different from those 
shown in Fig. 31 and Fig. 32). That is, in this specific 
20 example, cells coming from a dedicated VC are handed 
over from the ATM switch to the upper layer irrespective 
of whether or not the dedicated VC is directly linked with 
a downstream VC. Since the upper-layer processing 
section transfers the packets onto a downstream VC 
2S that is not directly linked, the destination node for which 
a direct link is not formed can also receive the multicast 
packets. 

Also, since the upper-layer processing section dis- 
cards unnecessary ones of the duplicated packets and 

30 does not output any packets onto the directly linked 
downstream dedicated VC, improper duplication does 
not occur. When R3 is notified that the packets flowing 
through VC1 are (S, G, 1) ) by S, R3 perfomns the set- 
up of the packet discarding table. Specifically, nnanaging 

55 section 309 of Fig. 29 creates an entry in input VC v 
flow table 311 of Fig. 33, and also creates an entry in 
packet discarding table 308 of Fig 33 to the effect that 
packets(S, G, 1 ) arriving from a VC other than VC are 
to be discarded 

40 Also, managing section 309 alters the ATM and IP 
routing tables to perform changeover between directly- 
linked transfer and hop-by-hop transfer, by using a di- 
rect-link management table, not shown in Fig. 29, as in 
embodiment 4 that will be described later. The input VC 

45 V. flow table 31 1 of Fig. 29 constitutes a part of the direct- 
link management table. Alternatively, the packet output 
processing of this embodiment can be implemented by 
the method of embodiment 2 described above. Specifi- 
cally, output processing is performed as shown in the 

50 flowchart of Fig. 15 (non-"best-match" searching meth- 
od). This may be done by adding an entry indicating that 
the output VC pointer of packets (S, G, 1) is "3" to the 
IP routing table of Fig. 32(a), and by writing output l/F = 
■upper layer", output VC = VC4, and next-pointer "X" at 

55 address "3" of Fig. 32(b). 

The characteristic features of this example may be 
summarized as follows. In order to transfer packets to 
a plurality of destination nodes in multicast communica- 
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tion, a router transfers packets received from a first node 
(subnet A) belonging to one logical network to a second 
node (subnet D) bebnging to another logical network. 
When the router receives some or all of the packets des- 
tined for the destination nodes in duplicated fashion 
from the first node through first and second virtual con- 
nections (VCD and VC1 ), the router selects the duplicat- 
ed packets from the packets received through the first 
virtual connection (VCO) and discard the selected pack- 
ets. If a correspondence relationship between the sec- 
ond virtual connection (VC1 ) and a third virtual connec- 
tion (VC3) that is capable of sending packets to the sec- 
ond node is stored in order to transfer packets by direct 
linking, the router transfers packets received through 
the second virtual connection (VC1 ) to the second node 
through a fourth virtual connection (VC2) other than the 
third virtual connection by copying the received packets 
for the network-layer processing. In contrast, if the sec- 
ond virtual connection is not directly linked, the router 
does not copy the packets. 

(Embodiment 3, Specific example 3) 

This specific example provides another method in 
the case where the CSR receives the duplicated pack- 
ets, as in embodiment 2. but eliminates the problem of 
chained duplication while ensuring that all the partici- 
pants will not fail to receive the multicast packets. 

If an upstream dedicated VC coming into the CSR 
is directly connected to one or more downstream dedi- 
cated VC, packets received from a default VC are not 
discarded. If the upstream dedicated VC is not directly 
linked with any downstream VC, packets received from 
the default VC are discarded in the input processing sec- 
tion as far as the packets are Identical to the packet flow 
flowing in the dedicated VC. 

The case where the dedicated VC Is directly linked 
will now be described with reference to Fig, 34. Input 
processing is performed as in the case of specific ex- 
ample 2 described above, and output processing is per- 
formed by ■best-match" searching in accordance with 
the flowchart of Fig. 25. Fig. 35 shows the IP routing 
table (Fig. 35(a) and Fig. 35(b)), packet discarding table 
(Fig, 35(c)), and input VC v. flow table (Fig. 35(d)) in this 
case. Since the input VC v. flow table indicates that VC 
1 is directly linked, nothing is written In the packet dis- 
carding table. Received packets are therefore not dis- 
carded. The received packets are sent to VC2 and VC4 
in accordance with the flowchart of Fig. 25. 

In contrast. Fig. 36 illustrates the case where the 
dedicated VC is not directly linked. Fig. 37 shows the IP 
routing table (Fig. 37(a) and Fig. 37(b)), packet discard- 
ing table (Fig. 37(c)), and input VC v. flow table (Fig. 37 
(d)) in this case. Since the input VC v. flow table indi- 
cates that VC1 is not directly connected, an entry is 
made in the packet discarding table to the effect that any 
packets (S, G, 1 ) except those arriving from VC1 (which 
is the dedicated VC) are to be discarded. Thus, packets 



(S, G, 1 ) are discarded if they come from VCO, but are 
subjected to output processing (not discarded) if they 
come from VC 1 . The output processing is in accord- 
ance with the flowchart of Fig. 25. Packets (S, G, 2) are 

5 output to VC2 and VC4, and packets (S, G, 1 ) are output 
to VC2, VC3 and VC4. 

The CSiR records the input VC and flow in the input 
VC V. flow table, when an upstream node notifies the 
CSR of a specified flow flowing through a given VC, and 

10 changes the status in the direct-link field of the corre- 
sponding entry, when a direct link is formed or released. 
The managing section of Fig. 29 alters the packet dis- 
carding table, when it finds that the direct-link fleld of the 
input VCv, flow table is changed from yes to no, or the 

IS reverse. 

Also, the managing section of Fig, 29 alters the ATM 
and IP routing tables in the case of changeover between 
directly-linked transfer and hop-by-hop transfer, using a 
direct-link management table, a part of which is the input 
20 VC v. flow table, as shown in embodiment 4 that will be 
described later Although not shown in Fig. 35 or Fig. 
37, the contents of the ATM routing table also is altered 
such that, if there is no direct link, cells coming from VCO 
and cells coming from VC1 are both transferred to the 
25 upper layer, whereas, if VC1 is directly linked with yC3, 
cells coming from VCO are transferred to the upper layer 
while cells coming from VC1 are transferred onto VC3. 

The characteristic features of this example may be 
summarized as follows. In order to transfer packets to 
30 a plurality of destination nodes in multicast communica- 
tion, a router transfers packets received from a flrst node 
(subnet A) belonging to one logical network to a second 
node (subnet D) belonging to another logical network. 
The router receives some or all of the packets destined 
35 for the destination nodes in duplicated fashion f rorn the 
flrst node through first and second virtual connections 
(VCO and VC1). If a correspondence relationship be- 
tween the second virtual connection (VC1 ) and a third 
virtual connection (VC3) that is capable of sending pack- 
40 ets to the second node is stored in order totransfer pack- 
ets by direct linking, the router transfers packets re- 
ceived through the flrst virtual connection (VCO) to the 
second node through a fourth virtual connection (VC2) 
other than the third virtual connection by processing the 
4s packets at the network layer. In contrasts if the second 
virtual connection is not directly linked, the router selects 
the duplicated packets from the packets received 
through the first virtual connection (VCO) and discard the 
selected packets. 
50 It can be said that embodiment 3/specific example 
2 is a method of discarding packets necessarily and cop- 
ying for the upper layer if necessary while embodiment 
3/specific example 3 is a method of discarding packets 
only in a case where the upper-layer processing section 
55 does not need the packets. 

It should be noted that in embodiment 3 packets 
transferred through the directly-linked virtual connection 
can be all the packets destined for the destination 
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nodes, or can be some (not all) of the packets, which 
belongs to a specified flow. The specified flow may be 
a flow for which a specified QOS is to be provided. 

In the latter case, the characteristic features of the 
above examples is applied to the packets belonging to 
the specified flow, while packets destined for the desti- 
nation nodes but not belonging to the specified flow are 
transferred using a default virtual connection which is 
not directly linked. The latter case includes the nnethod 
(corresponding to embodiment 3/specific example 1, 
embodiment 1) of transmitting packets belonging to the 
specified flow onto a virtual connection capable of being 
directly linked (i.e., dedicated VC) and transmitting other 
packets destined for the destinatbn nodes onto a virtual 
connection that is not directly linked (i.e.. default VC), 
and the method (corresponding to embodiment 3/spe- 
cific examples 2 and 3, embodiment 2) of transmitting 
packets belonging to the specified flow onto a dedicated 
VC and transmitting all the packets destined for the des- 
tination nodes onto a default VC. 

Also, when a dedicated VC is set up in response to 
a request originating from one of the destination nodes, 
a dedicated VC may be set up only between nodes on 
the route from source node to the destination node that 
originally sent this request, or, alternatively, a dedicated 
(point-multipoint) VC may be set up to all the next-hop 
rK)des connected to one output interface when one of 
the next-hop node is on the route to the destination node 
that originally sent this request. 

(Embodiment 4) 

When multicast packets are transferred by a CSR, 
it may happen that a plurality of output VCs exists cor- 
responding to one input flow. In this case, the load on 
the upper-layer processing sectbn can be reduced by 
copying cells using the copy function of the ATM switch. 

The configuration of the router of this embodiment 
is similar to Fig. 22 or Fig. 29. Now consider a case 
where, as in Fig. 38, the input VC is VCO and output 
VCs are VC1 and VC2, Input VCO is a VC for transfer- 
ring packets of source address S, destination address 
G. VC 1 and VC2 are VCs for sending packets of source 
address S, destination address G. The direct-link man- 
agement table of Fig. 39 is used to manage this infor- 
mation. 

The direct-fink management table is used by the 
routers of embodiments 3 through 5 in a similar way as 
in this embodiment, in order to set up the ATM routing 
table such as to link directly the input VC and output VCs 
that transfer the same flow. 

By setting up an ATM routing table in the switch as 
in Fig. 40, referring to the direct-link management table, 
cells arriving from VCO are transferred onto VC1 and 
VC2 without being handed over to the upper-layer 
processing section. This transfer is implemented by op- 
eration of the ATM switch in accordance with the flow- 
chart of Fig. 24. The load on the upper-tayer processing 



section is thereby lightened. 

The characteristic features of this embodiment may 
be summarized as follows. In order to transfer packets 
to a plurality of destination nodes in multicast commu- 
5 nication. a router transfers packets received from a first 
node (subnet A) belonging to one logical network to sec- 
ond and third nodes (subnets D and E) belonging to oth- 
er logical networks. The router stores a correspondence 
relationship between a first virtual connection (VCO) ca- 
pable of receiving packets from the first node and a sec: 
ond virtual connection (VC1 ) capable of sending pack- 
ets to the second node in order to transfer packets be- 
longing to a given flow to the second node, and further- 
more stores a correspondence relationship of the first 
virtual connection and a third virtual connection (VC2) 
that is capable of sending packets to the third node in 
order to transfer packets belonging to the flow to the 
third node. Then, the router transfers packets received 
through the first virtual connection in accordance with a 
plurality of stored correspondence relationships onto 
the second and third virtual connections with no or only 
a part of the network-layer processing. 

(Embodiment 5) 

When transferring multicast packets by a router 
having an ATM Switch (which may or may not be pro- 
vided with a directly-linked transfer function like the 
CSR), the toad on the upper-layer processing section 
can be lightened by copying the packets in the ATM 
switch instead of copying the packets in the upper-layer 
processing section, to transfer the identical packets to 
a plurality of output VCs. 

The configuration of the router of this embodiment 
is similar to Fig. 22 or Fig. 29 Now consider a case 
where, as in Fig. 41 , cells of source address S, destina- 
tion address G are received rom VCO. The ATM switch 
hands the received cells over to the upper-level 
processing section in accordance with the flowchart of 
Fig. 24. By searching the IP routing tables of Fig. 42 
using the packet destination as a key, in accordance 
with the flowchart of Fig. 5, the upper-layer processing 
section discovers that output l/F - d, output VC = VCS. 
Then, the upper-layer processing section converts the 
45 packet to cells and outputs the cells to VC3. The ATM 
switch inputs these cells and sends them to both output 
l/F = c, output VC = VC1 and output l/F = b, output VC 
= VC2, referring to the ATM routing tables of Fig. 43, in 
accordance with the flowchart of Fig. 24. 
so The characteristic features of this embodiment may 
be summarized as follows. In order to transfer packets 
to a plurality of destination nodes in multicast commu- 
nication, a router transfers packets received from a first 
node (subnet A) belonging to one logical network to sec- 
55 cxid and third nodes (subnets D and E) belonging to oth- 
er logical networks, through a switch that performs pack- 
et exchange using virtual connections. The router stores 
a correspondence relationship between a first virtual 
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connection (VC3) for transferring packets belonging to 
a given flow and second and third virtual connections 
(VC1 and VC2) capable of sending packets to the sec- 
ond and third nodes respectively, in the switch. The rout- 
er processes packets received fronn the first node 
(through VCO) at the network layer and outputs the proc- 
essed packets to the switch using the first virtual con- 
nection (VC3). Then^ the switch transfers these packets 
onto the second and third virtual connections (VC1 and 
VC2) in accordance with the stored correspondence re- 
lationship. 

Consequently, the switch function in the node cop- 
ies the packet so as to transnnit it onto a plurality of virtual 
connections, thereby speeding up multicast packet 
transfer by lightening the load on the network layer 

In addition to those already nnentioned above, per- 
sons of ordinary skill will realize that many modifications, 
variations and combinations of the above embodiments 
may be made without departing from the novel and ad- 
vantageous features of the present invention. 

Accordingly, all such modifications, variations and 
combinations are intended to be included within the 
scope of the appended claims. 

The specification and examples are only exemplary. 
The following claims define the true scope and sprit of 
the invention. 



Claims 

1 . A nriethod of transfemng a packet destined for a plu- 
rality of destination nodes in multicast communica- 
tion, in a network having a first node and a plurality 
of second nodes, comprising steps of: 



3. The method according to claim T, wherein the step 
of setting up includes substeps of: 

detecting a request of service quality for a spec- 
s ified flow issued by at least one of the destina- 

tion nodes; and 

setting up a virtual connection for transferring 
a packet belonging to the specified flow as one 
of said at least two of the plurality of virtual con- 
'fo nections, in response to the request. 

4. The method according to claim V further compris- 
ing steps of: 

transferring the packets received by one of the 
plurality of second nodes to a next-hop node 
using another plurality of virtual connections in 
another network, each of said another plurality 
of virtual connections being set up from said 
one of the plurality of second nodes to the next- 
hop node, so that the next-hop node receives 
the packets destined for the destinatbn nodes 
without duplication through one or more of said 
another plurality of virtual connections, when 
said another network or a network downstrieam 
of said another network contains a node having 
requested a service quality for a specified flow 
of the destination nodes; and 
transferring the packets received by one of the 
plurality of second nodes to a next-hop node 
using one virtual connection in another net- 
work, when neither said another network nor a 
network downstream of said another netv^ork 
contains a node having requested a service 
quality for a specified flow of the destination 
nodes. 

5. A method of transferring a plurality of packets, each 
of the plurality of packets being destined for a plu- 
rality of destination nodes in multicast communica- 
tion, in a network having a plurality of next-hop 
nodes and a plurality of virtual connections, each of 
the plurality of virtual connectbns being set up to 
one or more of the plurality of the next-hop nodes, 
comprising steps of: 

transmitting a first packet belonging to a spec- 
ified flow, the first packet being Included in the 
plurality of packets destined for the destination 
nodes, to the plurality of next-hop nodes 
through one or more of the plurality of virtual 
connections; and 

transmitting a second packet other than the 
specified flow, the second packet being includ- 
ed in the plurality of packets destined for the 
destination nodes, to the plurality of next-hop 
nodes through one or more of the virtual con- 
nections other than the virtual connection to be 



setting up a plurality of virtual connections in 
the network, each of the plurality of virtual con- 
nections being set up from the first node to one 
or more of the plurality of second nodes; and 
transmitting a plurality of packets destined for 40 
the destination nodes from the first node using 
the plurality of virtual connections, so that each 
of the plurality of second nodes receives the 
plurality of packets destined for the destination 
nodes without duplication through one or more ^5 
of the plurality of virtual connections and at 
least one of the plurality of second nodes re- 
ceives the plurality of packets through at least 
two of the plurality of virtual connections. 

so 

2. The method according to claim 1 , wherein the step 
of setting up includes a substep of 

setting up a virtual connection to be used to 
transmit packets for which a different service quality 
is requested to said at least one of the plurality of 55 
second nodes as one of said at least two of the plu- 
rality of virtual connections. 



25 



17 



33 



EP 0 818 903 A2 



34 



used in transmitting the first packet. 

A method of transferring a plurality of packets, each 
of the plurality of packets being destined for a plu- 
rality of destination nodes in multicast communica- 5 
tion, in a network having a plurality of next-hop 
nodes, a plurality of first virtual connections and a 
second virtual connection, the plurality of first virtual 
connections being set up to a specified one of the 
plurality of next-hop nodes, the second virtual con- 'fo 
nection being set up to one or more of the plurality 
of next-hop nodes other than the specified one, 
comprising steps of: 

transnnitting a first packet belonging to a spec- ^5 
ified flow, the first packet being included in the 
plurality of packets destined for the destination 
nodes to the plurality of next-hop nodes 
through one or more of the plurality of first vir- 
tual connections and the second virtual con- 20 
nection; and 

transmitting a second packet other than the 
specified flow, the second packet being includ- 
ed in the plurality of packets destined for the 
destination nodes, to the plurality of next-hop 2S 
nodes through one or more of the first virtual 
connections other than the virtual connection 
to be used in transmitting the first packet and 
the second virtual connection. 

30 

A node connected with a virtual-connection-orient- 
ed network, comprising: 

a memory for storing a plurality of identifiers of 
virtual connections to a next-hop node to be ^ 
used tor transferring packets destined for a plu- 
rality of destination nodes in multicast commu- 
nication; 

means for selecting one or more of the plurality 
of identifiers in the memory when a packet to -«> 
be transmitted is destined for the destination 
nodes and belongs to a specified flow, and for 
selecting the other of the plurality of identifiers 
in the memory when a packet to be transmitted 
Is destined for the destination nodes but does 45 
not belong to the specified flow; and 
means for transmitting a packet onto a virtual 
connection of the selected identifier. 

A node connected with a virtual-connection-orient- 
ed network, comprising: 

a memory for storing a plurality of identifiers of 
virtual connections to a next-hop node to be 
used for transferring packets destined for a plu- ss 
rality of destination nodes in multicast commu- 
nication; 

means for selecting at least two of the plurality 



of identifiers in the memory when a packet to 
be transmitted is destined for the destination 
nodes and belongs to a specified flow, and for 
selecting the other of the plurality of identifiers 
and at least one of said at least two of the plu- 
rality of identifiers in the memory when a packet 
to be transmitted is destined for the destination 
nodes but does not belong to the specified flow; 
and 

means for transmitting a packet onto a virtual 
connection of the selected identifier. 

9. A method of transferring a packet destined for a plu- 
rality of destination nodes in multicast communica- 
tion, in a network having a first node and a plurality 
of second nodes, comprising steps of: 

setting up a first virtual connection from the first 
node to the plurality of second nodes; 
setting up a second virtual connection from the 
first node to at least a specified one of the plu- 
rality of second nodes; 

transmitting a plurality of packets from the first 
node, so that each of the plurality of second 
nodes receives the packets destined for the 
destination nodes through the first virtual con- 
nection and at least the specified one of the plu- 
rality of second nodes receives the packets 
destined for the destination nodes and belong- 
ing to a specified flow also through the second 
virtual connection; and 

discarding the packets destined for the desti- 
nation nodes and belonging to the specified 
flow received through the first virtual connec- 
tion at the specified node. 

10. The method according to claim 9, wherein the step 
of setting up the second virtual connection includes 
substeps of: 

detecting a request of service quality for the 
specified flow issued by at least one of the des- 
tination nodes; and 

setting up a virtual connecttotf from the first 
node to one of the plurality of second nodes 
along a route to a node having requested the 
service quality of the desttnatlon nodes as the 
second virtual connections in response tn the 
request. 

11. A node connected with a virtual-con nection -orient- 
ed networi^, comprising: 

means for receiving a packet destined for a plu- 
rality of destination nodes in multicast commu- 
nication through a first virtual connection and a 
packet destined for the destination nodes and 
belonging to a specified fiow also through a 
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second virtual connection; 
means for discarding the packet destined for 
the destination nodes and belonging to the 
specified flow received through the first virtual 
connection; and 

means for processing the packet not discarded. 

12. The node according to claim 11, further comprising 

means for controlling the means for discard- 
ing by identifying the specified flow to be transferred 
through the second virtual connection. 

1 3. The node according to claim 1 1 , further comprising: 

a memory for storing a plurality of identifiers of 
virtual connections to a next-hop node to be 
used for transferring packets destined for the 
destination nodes; 

means for selecting one of the plurality of iden- 
tifiers in the memory when the packet proc- 
essed by the means for processing is destined 
for the destination nodes but does not belong 
to the specified flow, and for selecting the plu- 
rality of identifiers in the memory when the 
packet processed by the means for processing 
is destined for the destination nodes and be- 
longs to the specified flow; and 
means for transmitting the packet onto a virtual 
connection of the selected identifier. 

1 4. A method of transferring a packet destined for a plu- 
rality of destination nodes in multicast communica- 
tion from a first node belonging to one logical net- 
work to a plurality of second nodes, each of the plu- 
rality of second nodes belonging to another logical 
network different frorn said one logical network, 
comprising steps of: 

storing a correspondence relationship between 
a first virtual connection for receiving a storing 
a correspondence relationship between a first 
virtual connection for receiving a packet from 
the first node and a second virtual connection 
for transmitting the packet to a specified one of 
the plurality of second nodes; 
copying a packet received through the first vir- 
tual connection when It Is determined that one 
or more of the plurality of second nodes other 
than the specified one will not receive a packet 
destined for the destination nodes if the packet 
is transferred only in accordance with the 
stored correspondence relationship; 
transferring one copy of the packet^received 
through the first virtual connection onto the sec- 
ond virtual connection in accordance with the 
stored correspondence relationship; and 
transferring another copy of the packet re- 
ceived through the first virtual connection to 



said one or more of the plurality of second 
nodes other than the specified one by analyzing 
a destination address contained in the packet. 

s 15. The method according to claim 1 4, wherein the step 
of copying includes a substep of 

determining that one or more of the plurality 
of second nodes other than the specified one will 
not receive a packet destined for the destination 

10 nodes If the packet is transferred only in accordance 
with the stored correspondence relationship, when 
a third virtual connection other than the second vir- 
tual connection for which a correspondence rela- 
tionship with the first virtual connection is not stored 

IS exists corresponding to a flow to which a packet to 
be received through the first virtual connection be- 
longs. 

1 6. A method of transferring a packet destined for a plu- 
20 rality of destination nodes in multicast communica- 
tion from a first node belonging to one logical net- 
work to a second node belonging to another logical 
network, comprising steps of: 

2S receiving identical packets from the first node 

through first and second virtual connection; 
storing a correspondence relationship between 
the second virtual connection and a third virtual 
connection for transmitting a packet to the sec- 

30 end node; 

transferring a packet received through the sec- 
ond virtual connection onto the third virtual con- 
nection In accordance with the stored corre- 
spondence relationship; 

35 discarding an Identical packet received through 

the first virtual connection, to prevent both of 
the identrcal packets received through the first 
and second virtual connections from being sub- 
jected to a transfer by analyzing a destination 

40 address contained in a packet to be transferred; 

and 

transferring one of the identical packets re- 
ceived through the first and second virtual con- 
nections not being discarded onto a fourth vir- 
45 tual connection other than the third virtual con- 

nection by analyzing the destination address. 

1 7. A method of transferring a packet destined for a plu- 
rality of destination nodes in multicast communica- 

50 tion from a first node belonging to one logical net- 
work to a second node belonging to another logical 
network, comprising steps of: 

receiving Identical packets from the first node 
55 through first and second virtual connections; 

discarding an identical packet received through 

the first virtual connection; 

storing a correspondence relationship between 
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the second virtual connection and a third virtual 
connection for transmitting a packet to the sec- 
ond node; 

copying the packet received through the sec- 
ond virtual connection; 5 
transferring one copy of the packet received 
through the second virtual connection onto the 
third virtual connection in accordance with the 
stored correspondence relationship; and 
transferring another copy of the packet re- io 
ceived through the second virtual connection 
onto a fourth virtual connection other than the 
third virtual connection by analyzing a destina- 
tion address contained in the packet. 

IS 

1 8. A method of transferring a packet destined for a p lu- 
rality of destination nodes in multicast communica- 
tion from a first node belonging to one logical net- 
work to a second node belonging to another logical 
network, comprising steps of: 

receiving identical packets from the first node 
through first and second virtual connections; 
transferring a packet received through the sec- 
ond virtual connection onto a third virtual con- 2S 
nection for transmitting a packet to the second 
node in accordance with a correspondence re- 
lationship, when the correspondence relation- 
ship between the second virtual connection and 
the third virtual connection is stored; 30 
discarding an identical packet received through 
the first virtual connection, when the corre- 
spondence relationship is not stored; and 
transferring a packet received through the first 
virtual connection not being discarded onto a 55 
fourth virtual connectbn other than the third vir- 
tual connection by analyzing a destination ad- 
dress contained in the packet. 

19. A node for transferring a packet from a first node 40 
belonging to one logical network to a second node 
belonging to another bgical network, comprising: 

a memory for storing a correspondence rela- 
tionship between a first virtual connection for 45 
receiving a packet from the first node and a sec- 
ond virtual connection for transmitting the pack- 
et to the second node; 

first means for transferring a packet received 
from the first node to a next-hop node deter- so 
mined by analyzing a destination address con- 
tained in the packet; 

second m^ans for transferring a packet des- 
tined for a plurality of destination nodes in mul- 
ticast communk;ation received through the first 55 
virtual connection onto the second virtual con- 
nection in accordance with the correspondence 
relationship, when the correspondence rela- 



tionship is stored in the memory; and 
means for copying the packet received through 
the first virtual connection to hand over the 
packet to the first means, when it is determined 
that the next-hop node will not receive the pack- 
et destined for the destination nodes if the 
packet is transferred only by the second 
means. 

20. The node according to claim 1 9, wherein the means 
for copying includes 

means for determining that the next-hop node 
will riot receive the packet destined for the destina- 
tion nodes if the packet is transferred only by the 
second means, when the packet destined for the 
destination nodes is received only through the first 
virtual connection and a third virtual connection oth- 
er then the second virtual connection for which a 
correspondence relationship with the first virtual 
connection is not stored exists corresponding to a 
packet to be received through the first virtual con- 
nection. 

21. The node according to claim 1 9, further comprising 

means for discarding a packet received through 
another virtual connection different from the 
first virtual connection, when the packet re- 
ceived through said another virtual connection 
is identical to the packet received through the 
first virtual connection, 
and wherein the means for copying includes 
means for determining whether or not the next- 
hop node will not receive the packet destined 
for the destination nodes if the packet is trans- 
ferred only by the second means, depending on 
whether or not the correspondence relationship 
with the first virtual connection is stored in the 
memory. 

22. A node for transferring a packet from a first node 
betonging to one togical network to a second node 
betonging to another logical network comprising: 

a memory for storing a correspondence rela- 
tionship between a first virtual connection for 
receiving a packet from the first node and a sec- 
ond virtual connection for transmitting the pack- 
et to the second node; 

first means for transferring a packet received 
from the first node to a next-hop node deter- 
mined by analyzing a destination address con- 
tained in the packet; 

second means for transferring a packet re- 
ceived through the first virtual connection onto 
the second virtual connection in accordance 
with the stored correspondence relationship, 
when the correspondence relationship is stored 
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in the memory; and 

means for discarding a packet received through 
another virtual connection different from the 
first virtual connection before the packet is 
handed over to the first means, when the pack- s 
et received through said another virtual con- 
nection is identical to the packet received 
through the first virtual connection. 

23. The node according to claim 22, wherein the means io 
for discarding includes 

means for determining that the packet re- 
ceived through said another virtual connection 
should be discarded, when the correspondence re- 
lationship regarding the first virtual connection is not is 
stored in the memory. 

24. A method of transferring a packet destined for a plu- 
rality of destination nodes in multicast communica- 
tion from a first node belonging to one logical net- 
work through a switch for exchanging the packet to 
a second node and a third node belonging to anoth- 
er logical network different from said one logical net- 
work, comprising steps of: 

25 

Storing a correspondence relationship between 
a first virtual connection for transferring a pack- 
et and a second virtual connection for transmit- 
ting the packet to the second node and a third 
virtual connection for transmitting the packet to 30 
the third node; 

transferring a packet received from the first 
node through the first virtual connection to the 
switch by analyzing a destinatbn address con- 
tained in the packet; and 35 
transferring, by the switch, the packet received 
through the first virtual connection onto the sec- 
ond and third virtual connections in accordance 
with the stored correspondence relationship. 

25. A node for transferring a packet from a first node 
belonging to one logical network to a second node 
and a third node belonging to another logical net- 
work different from said one logical networks com- 
prising: 45 

a memory for storing a correspondence rela- 
tionship between a first virtual connection for 
transferring a packet and a second virtual con- 
nection for transmitting the packet to the sec- so 
ond node and a third virtual connection for 
transmitting the packet to the third node; 
a switch for transferring a packet received 
through the first virtual connection onto the sec- 
ond and third virtual connections in accordance ss 
with the stored correspondence relationship; 
and 

means for transferring a packet received from 



the first node to the switch through the first vir- 
tual connection by processing the packet at a 
network layer. 
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